Die weltweit erste Website bestand lediglich aus reinem Text und Hyperlinks. Aussehen, Verhalten und Nutzung des Internets haben sich seitdem radikal verändert. Das Web wurde zu einer interaktiven Plattform, die Nutzer:innen aktiv mitgestalten können. Jede der Sites und Anwendungen enthält Inhalte, die verwaltet und bearbeitet werden müssen. Doch nicht bei jeder inhaltlichen Änderung soll gleich ein Entwicklerteam beauftragt werden. Die Lösung bieten Content-Management-Systeme (CMS), denn sie ermöglichen es, Inhalte und Medien zu verwalten und zu veröffentlichen (Abb. 1).

Abb. 1: Funktionsweise eines klassischen CMS

Warum Headless?

Die aktuellen Trends im Web und die voranschreitende Digitalisierung stellen CMS vor neue Herausforderungen. Im Zeitalter internetfähiger Kühlschränke genügt es nicht mehr, eine responsive Website zu betreiben. Heterogene Ausgabegeräte benötigen häufig eine speziell auf den jeweiligen Kanal zugeschnittene Anwendung. Der Inhalt ist hingegen überall gleich – zumindest in Teilen. Damit er nicht mehrmals an unterschiedlicher Stelle erzeugt und gepflegt werden muss, wurde in den letzten Jahren das Konzept der Headless CMS entwickelt.

Abb. 2: Funktionsweise eines Headless CMS

Ein Headless CMS hat die Vorteile klassischer CMS, bietet also einen Administrationsbereich, in dem Content Creators Inhalte anlegen und verwalten können. Gleichzeitig ist es nicht mehr an ein einziges Frontend gebunden. Das ist nämlich komplett vom Backend entkoppelt: Die Daten können über eine standardisierte Schnittstelle abgerufen und auf einem beliebigen Frontend dargestellt werden (Abb. 2).

Trends von Content-Management-Systemen

Knapp 40 Prozent aller Websites verwenden ein CMS [1]. Durch die rasante Entwicklung und Digitalisierung müssen CMS immer mehr leisten:

• Ausgabekanäle: Mit der Digitalisierung existieren immer mehr internetfähige Geräte, mehr Anwender, mehr Software und mehr Content. Ein modernes CMS muss Inhalte für beliebige Anwendungen, native Apps, Webshops, E-Mail, Marketing, Intranet etc. bereitstellen können.

• Frameworks: Mit Headless CMS können beliebige Frontend-Frameworks genutzt werden. Mit Frameworks sparen Entwickler:innen Zeit und Kosten, um eine Website zu erstellen, da sie vorgefertigte Komponenten und den „Baukasten“ ihrer Wahl nutzen können.

• Cloud: Moderne CMS sind über den Browser als universale Schnittstelle bedienbar und können ohne eigenen Installationsaufwand in der Cloud bereitgestellt und auch skaliert werden.

• Usability und User Experience: Gute CMS sollten einen einfach bedienbaren Administrationsbereich haben, um den Lernaufwand der Nutzer:innen mit unterschiedlichen Vorkenntnissen gering zu halten. Außerdem sollten sie den Redakteur:innen Freiraum für individuelle Gestaltung bieten.

• Content Delivery Networks (CDNs): Endnutzer:innen gehen davon aus, dass eine Website schnell lädt. Die Conversion Rate sinkt, wenn die Seite nicht innerhalb von 2,4 Sekunden geladen ist [1]. CDNs können im Zusammenspiel mit CMS dabei helfen, dass der Inhalt schnell bei den Nutzenden ankommt. Sie verringern die Latenz und helfen, Infrastruktur gleichmäßig auszulasten.

• Search Engine Optimization (SEO): Wird eine Website für Suchmaschinen optimiert, kann sie schneller gefunden werden, was wiederum zu einer höheren Conversion Rate führt. Dazu müssen Metadaten für den Inhalt festgelegt werden. Moderne CMS bieten einfache Möglichkeiten, Metadaten wie den Titel, eine Bildbeschreibung oder Keywords festzulegen.

• Sicherheit: Um sich vor Hackerangriffen zu schützen, benötigt ein CMS bestmögliche Sicherheitsmechanismen. Dazu gehören ein Authentifizierungs- und Autorisierungskonzept, um zu bestimmen, wer auf welche Daten zugreifen kann, und die Verschlüsselung vertraulicher Daten.

• Verschmelzung von Content und E-Commerce: Moderne CMS kombinieren Inhalte mit Produkten und Dienstleistungen. Kunden sollen persönlich angesprochen werden, indem das CMS etwa den Aufenthaltsort, die Zeitzone oder das genutzte Endgerät auswertet. Zum Einsatz kommen beispielsweise integrierte KI-basierte Chatbots.

• Headless und Microservices: Headless CMS sind Teil des JAM-Stacks (JavaScript API Markup). Die Inhalte werden mittels API an ein beliebiges JavaScript Framework angebunden, sodass kein monolithisches System entsteht. Das CMS bleibt modular und Entwickler:innen können selbst bestimmen, wo und wie die Daten gespeichert und wie die Website gerendert wird.

Headless CMS im Vergleich: WordPress, Strapi und Sanity

Nun wollen wir drei populäre Headless CMS vergleichen. WordPress wurde 2003 von Mike Little und Matt Mullenweg entwickelt und diente ursprünglich als Blogveröffentlichungsplattform. Das traditionelle CMS bietet ebenfalls die Möglichkeit, die Daten über ein API abzurufen. Wegen der riesigen Community rund um WordPress und weil das CMS so viel genutzt wird, darf es in diesem Vergleich nicht fehlen.

Strapi wurde 2015 gegründet und ist ein auf Node.js basierendes Headless CMS. Es hat sich vor allem auf die Erstellung des API spezialisiert, das sich flexibel anpassen lässt, sodass es den Bedürfnissen der Nutzenden entspricht.

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Sanity.io ist ein CMS, das 2017 entwickelt wurde. Es wirbt mit der Vereinheitlichung und Strukturierung von Inhalten. Sanity ist als Software as a Service (SaaS) erhältlich, sodass die Inhalte direkt in einer Cloud gespeichert und den Nutzenden zur Verfügung gestellt werden.

Im Folgenden werfen wir nun einen detaillierteren Blick auf eine Auswahl wichtiger Merkmale moderner Headless-CMS:

• API,

• Hosting,

• Content Modeling,

• Gestaltungsfreiheit für Webredakteur:innen sowie

• Preismodelle.

Das Herzstück eines Headless CMS: das API

Das Application Programming Interface (API) dient als Schnittstelle zwischen dem Headless CMS und einem oder mehreren Frontends. Das Programmierparadigma REST bildet hier den Standard im Web, sodass RESTful APIs von fast jedem internetfähigen Gerät genutzt werden können. RESTful APIs haben allerdings auch einige Nachteile, wie das Over- und Underfetching. Overfetching beschreibt, dass alle verfügbaren Inhalte einer Ressource zurückgegeben werden, auch wenn sie nicht benötigt werden. Underfetching bedeutet, dass immer nur ein Endpunkt gleichzeitig abgerufen werden kann. Sollen mehrere Ressourcen angefragt werden, muss das nacheinander geschehen.

Neue Abfragetechnologien versprechen, diese Probleme zu lösen. Zu den bekanntesten zählt GraphQL. Im Gegensatz zu RESTful APIs strukturiert GraphQL die Daten nicht nach Ressourcen, sondern nach Typen und deren Attributen. Dadurch gibt es nur einen Endpunkt, mit dem mehrere Ressourcen abgefragt werden können. Der Request kann außerdem so definiert und gefiltert werden, dass nur die tatsächlich benötigten Daten zurückgegeben werden.

RESTful APIs, GraphQL oder CROQ

Das System Strapi nutzt standardmäßig ein REST API, das es erlaubt, Inhaltstypen durch Endpunkte zu erreichen. Es werden automatisch Endpunkte für CRUD-(Create-Read-Update-Delete-)Funktionalitäten erstellt. Zudem gibt es die Möglichkeit, Endpunkte anders zu benennen und zu verändern. Dabei können Endpunkte komplett oder teilweise deaktiviert, mit berechneten Daten gefüllt oder komplett überschrieben werden. Zusätzlich bietet Strapi die Möglichkeit, über ein Plug-in auch das GraphQL API zu nutzen. GraphQL erstellt automatisch für jeden Inhaltstyp Querys und Mutations.

WordPress ist zwar kein Headless CMS, bietet aber ein REST API an, das standardmäßig unter dem folgenden URL abgefragt werden kann: https://<wordpress-site-url>/wp-json/. Zusätzlich können durch Plug-ins weitere Abfragesprachen wie GraphQL genutzt werden. WordPress generiert automatisch API-Endpunkte, mittels PHP können aber auch eigene Endpunkte definiert werden.

Sanity verwendet standardmäßig die hauseigene Abfragesprache CROQ. CROQ steht für Graph Rational Object Queries und wurde speziell für den Einsatz dieses CMS entwickelt. Ebenso wie bei GraphQL werden nur die benötigten Daten abgerufen, Informationen aus verschiedenen Ressourcen verbunden und in einer Antwort zurückgegeben, die individuell strukturiert werden kann. Mit CROQ können Ressourcen nur abgefragt und nicht verändert werden. Eine beispielhafte Abfrage wird im nachstehenden Code gezeigt, in dem alle Künstler mit Namen, einem Link zur entsprechenden Künstlerwebsite und Kunstwerken zurückgegeben werden. Als Kunstwerke werden alle Objekte geladen, die dem jeweiligen Künstler zugeordnet wurden. Darüber hinaus bietet Sanity auch ein GraphQL API an. Allerdings können hier nur Querys und keine Mutations verwendet werden. Um Inhalte zu verändern, kann ein REST API genutzt werden.

*[ _type == "artist"]{
  name,
  "link": slug.current,
  "artworks": *[_type == "artworks" && artist._ref == ^._id]
 }

Cloud-Hosting

Hosting ist ein wichtiges Kriterium, da es über die Verfügbarkeit der Daten und die Geschwindigkeit der Website Aufschluss gibt. Moderne CMS setzen auf Cloud-Hosting. Dabei liegt das CMS auf mehreren miteinander verbundenen Servern. Die Auslastung kann auf mehrere Server verteilt werden, was zu einer besseren Performance führt. Meist wird die Cloud durch das Pay-as-you-go-Preismodell abgerechnet, sodass nur das gezahlt wird, was wirklich genutzt wird. Da die Rechenkapazität einfach skaliert werden kann (durch Ab- und Zuschalten von Servern) wird eine enorme Flexibilität erreicht. Zudem wird die Verfügbarkeit garantiert.

Strapi ist eine Open-Source-Software und kann on-premises, also in einer eigenen Umgebung, gehostet werden. Alternativ stehen Leitfäden bereit, um die Software manuell auf einen Cloudanbieter wie AWS oder Azure zu deployen. Ein vom Unternehmen angebotenes Cloud-Hosting befindet sich derzeit noch im Aufbau.

Bei Sanity ist die Verwaltungsumgebung Sanity Studio Open Source. Das CMS kann damit lokal getestet und aufgesetzt werden, das API wird allerdings auf den Servern des Unternehmens gehostet. Das bringt einige Vorteile mit sich: Das Deployment ist mit nur einem Befehl erledigt, und Sanity stellt nicht nur die Pipeline und Kapazität zur Verfügung, sondern kümmert sich gleich selbst um regelmäßige Updates und Backups.

Beim Open-Source-Platzhirsch WordPress kann man auf sämtliche Möglichkeiten und fast unzählige Hostinganbieter zurückgreifen. Viele Unternehmen bieten beispielsweise eine Ein-Klick-Installation mit regelmäßigen Updates und Backups an.

Schneller an die Inhalte: Content Delivery Networks

In unserer schnelllebigen Zeit ist es wichtig, dass Kund:innen und Nutzer:innen schnell auf die Inhalte Zugriff haben. Content Delivery Networks (CDNs, Abb. 3) sind geografisch sinnvoll verteilte Server, die für ein schnelles Bereitstellen von Internetinhalten sorgen. Um die Latenz möglichst gering zu halten und damit eine bessere User Experience zu gewährleisten, speichern CDNs Kopien von Webinhalten auf sogenannten PoPs (Points of Presence). Damit kann der Caching-Server, der physikalisch dem Client am nächsten ist, die Inhalte bereitstellen. Das hat noch einen weiteren Vorteil: Dank des temporären Speicherns können Inhalte effizient für mehrere Nutzende bereitgestellt werden. So werden Netzwerküberlastungen verhindert.

Sanity stellt CDNs für Assets und das API bereit. Die Asset-CDNs basieren auf Google-Services und cachen Bilder, Videos und andere Formate. Um die API-CDNs zu nutzen, kann statt dem URL api.sanity.io einfach apicdn.sanity.io angesprochen werden.

Abb. 3: Funktionsweise eines Content Delivery Networks

Unterschied zwischen Cloud und CDNs

Cloud-Hosting und die Verwendung eines CDN sind sehr ähnlich, denn beide speichern Inhalte auf mehreren geografisch verteilten Servern. Sie unterscheiden sich allerdings in ihrem Verwendungszweck: CDNs sind keine Webhosts. Sie sind lediglich für das Zwischenspeichern von Caching-Daten verantwortlich, um Inhalte näher und schneller an Endkonsument:innen zu bringen. Cloud-Hosting wiederum wird verwendet, um flexibel und bei Bedarf kurzzeitig mehr Kapazitäten für das Hosting und das Bereitstellen von Daten zu ermöglichen.

Content First

Content Modeling beschreibt den Prozess, mit dem eine logische Struktur erstellt wird, in der Inhalte gespeichert werden können. In einem Content Model werden einzelne Inhaltstypen, eine Art Template, mit ihren Attributen definiert und im Detail beschrieben. Die Attribute sind gewöhnlich Inputblöcke, in die Inhalt eingetragen werden kann. Das können ein Text, eine Zahl, Medien, eine Enumeration oder andere CMS-spezifische Inhaltstypen sein.

Wie in Abbildung 4 dargestellt, sollten alle Informationen auf kleinstmögliche Datenstücke heruntergebrochen und sinnvoll beschriftet werden. Der Inhaltstyp „Katze“ hat hier die Attribute „Name“ (Text), „Alter“ (Nummer) und „Bild“ (Media). Von einem Inhaltstyp können mehrere Instanzen angelegt werden, in diesem Beispiel Katze #1 und Katze #2.

Abb. 4: Beispiele für einen Content Type und dessen Attribute

Content Hub durch strukturierten Inhalt

Alle CMS nutzen ein Content Model zur Strukturierung des Inhalts. Doch vor allem Headless CMS folgen dem sogenannten Content-first-Ansatz, da sie sich auf die Strukturierung der Inhalte konzentrieren und nicht auf deren Darstellung. Klassische CMS wie Drupal oder Typo3 haben nur wenig Struktur: Die Inhaltstypen sind fest vordefiniert (z. B. Websites, Blogposts und User) und nur schwer erweiterbar. Zudem haben die Inhaltstypen nur wenige Attribute, wie in Abbildung 5 auf der linken Seite dargestellt ist. Der Inhaltstyp Website hat beispielsweise nur das Attribut header und body, in dem alle Inhalte, wie Texte, Bilder und Videos eingefügt und formatiert werden.

Im Gegensatz dazu können mit CMS wie Strapi eigene Inhaltstypen definiert werden. Eine Website über Künstler könnte zum Beispiel die Inhaltstypen Künstler, Kunstwerk, Blogbeitrag und Website haben. Jeder dieser Inhaltstypen kann mit beliebig vielen und unterschiedlichen Attributen ausgestattet werden (Abb. 5, rechte Seite).

Abb. 5: Links unstrukturierter Inhalt mit wenigen Attributen, rechts strukturierter Inhalt

WordPress speichert Inhalte nur bedingt strukturiert

WordPress bietet von Haus aus keine Möglichkeit, eigene Inhaltstypen zu erstellen. Da WordPress ein klassisches CMS ist, ist es nicht auf diese Art der Inhaltsstrukturierung ausgelegt. Standardmäßig verfügt WordPress über sieben Content Types, genannt Post Types. Über Plug-ins oder im Code mit PHP können auch eigene Types erstellt werden. Bekannte Plug-ins sind dafür das „Custom Post Type UI“ oder „Advanced Custom Fields“. Bei der Wahl des Plug-ins muss auf die Erstellung von API-Endpunkten geachtet werden. Nicht jedes Plug-in erstellt automatisch Schnittstellen mit den CRUD-Funktionen. Teilweise müssen sie im Code selbst erstellt werden.

Sanity und Strapi bieten mehr Möglichkeiten

Sanity und Strapi bieten für das Content Model vergleichbare Funktionalitäten, wobei sie sich vor allem in der Erstellung unterscheiden. Strapi bietet für die Erstellung der Inhaltstypen und -attribute ein intuitives User Interface, mit dem alle Optionen ausgewählt und definiert werden können. Bei Sanity müssen die Inhaltstypen und -attribute im Code festgelegt werden. Das ist anfangs aufwendiger, da die Möglichkeiten von Attributen und deren Optionen in der Dokumentation nachgelesen werden müssen. Gleichzeitig bietet das mehr Freiheiten in der Erstellung und Verschachtelung. Besonders interessant sind dabei spezielle Inhaltstypen, die dem größten Nachteil von strukturiertem Inhalt entgegenwirken sollen: Komponenten und Arrays ermöglichen Redakteur:innen mehr Freiheit in der Gestaltung der Inhalte.

Inhaltsattribute für mehr Gestaltungsspielraum

Jedes CMS bietet eigene Attribute an. Folgende sind allerdings bei der Mehrheit vertreten:

• RichText ist Text, der neben dem Inhalt auch Formatinformationen speichert.

• Komponenten bündeln mehrere Attribute zu einem neuen Attribut, zum Beispiel Vorname und Nachname. Diese können meist von allen Inhaltstypen verwendet werden.

• Wiederholbare Komponenten sind Komponenten, die mehrmals verwendet werden können, z. B. können für einen Inhaltstyp „Workshop“ mehrere Termine eingetragen werden, jeweils mit den Attributen Uhrzeit und Ort.

• Durch Arrays können Redakteur:innen aktiv die Reihenfolge des Layouts mitbestimmen. In diesen Zonen können Komponenten definiert werden, die von den Redakteur:innen nach Belieben verwendet und strukturiert werden können. Wie in Abbildung 6 zu sehen ist, kann in einem Array eine Komponente erstellt und mit Drag-and-drop in die gewünschte Reihenfolge gebracht werden. Redakteur:innen können dadurch zum Beispiel entscheiden, ob sie zuerst ein Bild und dann den Text platzieren möchten oder umgekehrt.

Abb. 6: Mit Arrays kann das Layout beeinflusst werden (Sanity Studio)

Gestaltungsmöglichkeiten für Redakteur:innen

Ein Attribut kann auch ein RichText-Feld sein, wie z. B. in Abbildung 5 auf der linken Seite das „Body“-Element. Für den RichText gibt es oft WYSIWYG-(What-you-See-Is-What-You-Get-) Editoren, mit denen grundlegende Formatierungen möglich sind wie Schriftgröße oder -farbe. Allerdings sind diese Editoren auch stark in der Gestaltung von Layouts eingeschränkt und machen das Verwenden von Inhaltstypen innerhalb des RichTexts schwer.

WordPress verwendet seit 2018 als Standard-WYSIWYG-Editor den Gutenberg-Editor. Dieser speichert den Inhalt in eigenen Blöcken ab, sodass diese leicht per Drag and Drop verschoben und manipuliert werden können. Die „Blöcke“ des Gutenberg-Editors werden allerdings nicht als einzelne Objekte abgespeichert. Sie sind über das API daher nicht einzeln erreichbar. Die Nutzenden des API bekommen daher nicht selten ein riesiges HTML-Objekt zurück.

Da Headless CMS für getrennte Speicherung von Inhalten und Darstellung ausgelegt sind, wird RichText im Frontend nicht automatisch mit den gleichen Formatierungen angezeigt, die im CMS vorgenommen wurden. CSS-Klassen werden zwar in HTML gespeichert und in der API-Response mit überliefert, aber solange die CSS Styles im Frontend nicht definiert werden, können die Styles nicht angezeigt werden.

Strapi nutzt deshalb keinen WYSIWYG-Editor, sondern Markdown. Durch die simple Syntax ist Markdown leichtgewichtig und verhindert Fehler in der Semantik. Mit Markdown kann eine Überschrift nicht eingefärbt oder in der Größe verändert, sondern nur dem semantischen Zweck zugeordnet werden. Die Semantik kann dann einfacher im Frontend gestylt werden.

Preisvergleich

Alle drei untersuchten CMS bieten eine kostenlose Version an, die für private, aber auch kleinere Projekte ausreichend ist. Strapi als selbstgehostete Software beschränkt in der kostenfreien Version die Support- und Autorisierungsfunktionalitäten. Ein um einige Funktionalitäten und Support erweiterter Tarif ist ab 9 $ pro Monat (ohne Hosting) erhältlich. Sanity, das nur als SaaS-Produkt (also mit Hosting) vom Unternehmen erworben werden kann, beschränkt in der kostenlosen Version beispielsweise die Anzahl der Nicht-Admin-Nutzer:innen sowie Bandbreite, Medien, Speicherplatz etc. Für kleine Teams existiert ein Preismodell ab 99 $ pro Monat.

WordPress ist damit schwer zu vergleichen, da die Kosten und das Angebot je nach Hostinganbieter stark variieren. Dabei sollte nicht vergessen werden, dass die Kosten für mögliche Plug-ins noch dazu kommen können.

Fazit: Strapi für größere Projekte empfehlenswert

Durch die große Anpassbarkeit und Personalisierungen empfiehlt sich Strapi vor allem für größere Projekte. Das API kann mit eigenen Endpunkten angepasst werden, und durch Zugriffsberechtigungen wird genau definiert, wer welche Informationen abrufen darf. Strapi zeichnet sich durch ein sehr intuitives User Interface aus, das alle Inhalte sortieren und durchsuchen kann. Mit dem Content Type Builder können die Inhaltstypen und ihre Attribute einfach über das Interface zusammengestellt werden (Abb. 7).

Abb. 7: Der Content Type Builder von Strapi erlaubt es, die Inhaltstypen über ein GUI zu erstellen

Außerdem bietet Strapi Redakteur:innen die Möglichkeit, sich selbst in die Gestaltung miteinzubringen: Es gibt einen Markdown-Editor und Dynamic Zones, eine Art Array, durch die das CMS zu einem Drag-and-Drop-Editor werden kann. Trotzdem kann das Webdesign komplett unabhängig im Frontend gestylt werden.

Durch eigenes Hosting hat man Kontrolle und Sicherheit über seine Daten. Gleichzeitig ist das Hosting auch der größte Kritikpunkt an Strapi: Das Set-up ist relativ komplex und zeitaufwendig, ist also nicht für Anfänger geeignet. Außerdem bietet Strapi momentan (Stand November 2022) noch kein eigenes Cloud-Hosting an.

Tabelle 1: Vergleich der drei Systeme im Überblick

Sanity als Allrounder

Sanity ist besonders für kleine bis mittelgroße Projekte geeignet. Sanity folgt dem Content-first-Ansatz durch und durch: Jedes bisschen Information wird in einem separaten Block gespeichert und ist über das API abrufbar. Sanity enthält dafür nicht nur viele verschiedene Content Types für jede Art von Attributen, sondern strukturiert selbst den Inhalt des Editors in einzelne JSON-Objekte.

Außerdem ist Sanity vor allem eins: schnell. Mittels eines Befehls kann das in Sanity Studio lokal entwickelte Projekt deployt werden und ist bereit für die Nutzung. Für eine bessere Performance verwendet Sanity CDNs für das Caching von Assets und Informationen. Auch Bilder können optimiert und ein Hotspot kann gewählt werden, damit die wichtigen Aspekte des Bildes immer angezeigt werden.

Standardmäßig bietet Sanity CROQ für Abfragen an, um möglichst zielgenaue Querys zu formulieren. Dennoch benötigt es einigen Zeitaufwand, die Abfragesprache zu lernen. Ein weiterer Nachteil ist, dass Nutzer:innen des API nicht in Rollen zusammengefasst werden und ihre Rechte eingeschränkt werden können. Außerdem bietet Sanity kein Hosting auf eigenen Servern (on-premises), was für größere Projekte mit sensiblen Daten unattraktiv sein kann.

WordPress kann als Headless CMS nicht mithalten

WordPress sollte als Headless CMS nur genutzt werden, wenn es ausdrücklich gewünscht ist. Der größte Vorteil liegt in dem vertrauten User Interface. Da WordPress so beliebt ist, haben schon viele Content Creators damit gearbeitet und kennen sich aus, was die Eingewöhnungszeit merklich verkürzt. Die größten Schwierigkeiten liegen in der Erstellung eines feingliedrigen Content Models. Eigene Inhaltstypen und ihre Attribute können nur über ein Plug-in erstellt werden. Je nach Plug-in werden so auch keine eigenen Endpunkte generiert, sodass diese selbst im Code definiert werden müssen.

Fazit

Wenn es gilt, für die Zukunft mit unterschiedlichsten internetfähigen Geräten gerüstet zu sein, sollte heutzutage ein Headless CMS genutzt werden. Dabei sollte das Hosting in Augenschein genommen werden – es ist wichtig, da von ihm Skalierbarkeit und Datensicherheit abhängen.

Das Herzstück eines Headless CMS ist der Umgang mit dem Inhalt. Wie wird der Inhalt strukturiert und gespeichert? Wie können Inhaltstypen erstellt werden und welche Felder werden benötigt? Wie können die Daten abgerufen werden? Diese Fragen sollten auf jeden Fall vor der Entscheidung für oder gegen ein bestimmtes CMS beantwortet werden, um eine bessere Vorstellung zu haben, wie das Content Model aussehen könnte.

Werden für ein Projekt vor allem große gestalterische Freiheiten für die Redakteur:innen benötigt, sollte man sich über deren Umfang im Klaren sein. Oft ist es ausreichend, das Layout nach Belieben aus Komponenten zusammenzustellen. Mehr Freiheiten könnten WYSIWYG-Editoren bieten, wobei die Herausforderungen der Darstellung auf multimedialen Geräten (Stichwort Responsivität) nicht vergessen werden dürfen. Je nach Projekt und Nutzergruppe sind die Kriterien also unterschiedlich zu gewichten.

Darüber hinaus existieren weitere Architekturen für das Verwalten von (Web-)Inhalten, wie beispielsweise Flat File CMS oder AEM/DXP. Diese haben ihre ganz eigenen spezifischen Vor- und Nachteile und wurden im Rahmen der zugrunde liegenden Arbeit [3] nicht berücksichtigt. Das Web entwickelt sich jedenfalls immer weiter. Wer weiß, welche Geräte in Zukunft daran angeschlossen werden und Informationen benötigen. Ein Headless-CMS bietet hierfür jedenfalls aktuell noch die passenden Möglichkeiten.

Links & Literatur

[1] W3Tech: „Usage statistics of content management systems“:https://w3techs.com/technologies/overview/content_management

[2] JustRelate Group GmbH: „Top Trends für das Content Management 2020: Headless, Serverless, JAMstack“:https://www.justrelate.com/de/top-trends-fuer-das-content management-2020-973d9699cfcdbe92

[3] Raps, Sophie: „Vergleich und Einsatz verschiedener CMS in der Headless Architektur“, Bachelor Thesis an der RWU Hochschule Ravensburg-Weingarten im Studiengang Mediendesign, 2022